1. Field of the Disclosure
The technology of the disclosure relates generally to Web Real-Time Communications (WebRTC) interactive sessions.
2. Technical Background
Web Real-Time Communications (WebRTC) is an ongoing effort to develop industry standards for integrating real-time communications functionality into web clients, such as web browsers, to enable direct interaction with other web clients. This real-time communications functionality is accessible by web developers via standard markup tags, such as those provided by version 5 of the Hyper Text Markup Language (HTML5), and client-side scripting Application Programming Interfaces (APIs) such as JavaScript APIs. More information regarding WebRTC may be found in “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” by Alan B. Johnston and Daniel C. Burnett, 2nd Edition (2013 Digital Codex LLC), which is incorporated in its entirety herein by reference.
WebRTC provides built-in capabilities for establishing real-time video, audio, and/or data streams in both point-to-point interactive sessions and multi-party interactive sessions. The WebRTC standards are currently under joint development by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). Information on the current state of WebRTC standards can be found at, e.g., http://www.w3c.org and http://www.ietf.org.
In a typical WebRTC exchange, two WebRTC clients retrieve WebRTC-enabled web applications, such as HTML5/JavaScript web applications, from a web application server. Through the web applications, the two WebRTC clients then engage in an initiation dialogue for initiating a peer connection over which a WebRTC interactive flow (e.g., a real-time video, audio, and/or data exchange) will pass. This initiation dialogue may include a media negotiation used to communicate and reach an agreement on parameters that define characteristics of the WebRTC interactive session.
In some embodiments, the media negotiation may be implemented via a WebRTC offer/answer exchange via a secure network connection such as a Hyper Text Transfer Protocol Secure (HTTPS) connection or a Secure WebSockets connection. In a WebRTC offer/answer exchange, a first WebRTC client sends a WebRTC session description object “offer,” which may specify the first WebRTC client's preferred media types and capabilities, to a second WebRTC client. The second WebRTC client then responds with a WebRTC session description object “answer” that indicates which of the offered media types and capabilities are supported and acceptable by the second WebRTC client for the WebRTC interactive session.
Once the initiation dialogue is complete, the WebRTC clients may then establish a direct peer connection with one another, and may begin an exchange of media or data packets transporting real-time communications. The peer connection between the WebRTC clients typically employs the Secure Real-time Transport Protocol (SRTP) to transport real-time media flows, and may utilize various other protocols for real-time data interchange. It is to be understood that the initiation dialogue may employ mechanisms other than a WebRTC offer/answer exchange to establish a WebRTC interactive flow between WebRTC endpoints.
WebRTC also specifies a mechanism for authenticating an identity of a WebRTC client involved in an initiation dialogue (and thus, the peer connection and the WebRTC interactive flow established as a result of the initiation dialogue) through the use of a web-based entity known as an Identity Provider (IdP). This mechanism is described in section 8, “Identity,” in the “WebRTC 1.0: Real-time Communication Between Browsers” document available online at, e.g., http://dev.w3.org/2011/webrtc/editor/webrtc.html. To authenticate an identity, the WebRTC client of a participant seeking authentication (the Authenticating Party, or AP) first downloads an authentication application from the IdP. As an example, the authentication application may be a JavaScript web application that implements a generic WebRTC protocol for requesting and verifying identity assertions. The authentication application may also provide specialized logic based on the specific requirements of the IdP. Using the authentication application, the AP obtains an “identity assertion” from the IdP. The process for obtaining an identity assertion may involve, for example, the AP logging into or otherwise providing credentials to the IdP. The WebRTC client of the AP then provides the identity assertion as part of the initiation dialogue. For instance, in the context of a WebRTC offer/answer exchange, the WebRTC client of the AP may attach the identity assertion obtained from the IdP to the offer/answer. The recipient of the offer/answer, known as the Relying Party (RP), then downloads a verification application from the same IdP, and uses it to verify the identity assertion, and, by extension, the identity of the AP.
A WebRTC client may employ a custom IdP for identity assertion, where the custom IdP is programmatically specified by an IdP identifier in a downloaded WebRTC web application through the use of instructions (e.g., the setIdentityProvider instruction). Alternatively, a default IdP identifier may be stored in settings for the WebRTC client for use in the absence of a web-application-specified custom IdP identifier. Thus, in a typical scenario, two IdP identifiers at most are available for a given WebRTC interactive flow, with the WebRTC web application determining whether the custom IdP identifier or the default IdP identifier will be used. However, in some circumstances, this may not provide sufficient control or flexibility over the IdP identifiers to be used for a given WebRTC interactive flow. In the context of WebRTC clients within an enterprise network, an enterprise may wish to specify an enterprise policy for providing more than two IdP identifiers for a WebRTC client, and/or for prioritizing multiple IdP identifiers for use in different communications scenarios. For instance, the enterprise may wish to designate a specific IdP identifier to be employed by all WebRTC clients within an enterprise network regardless of the web-application-specified custom IdP identifiers and/or the default IdP identifiers.